fix: recover broken publish paths and stuck reconnects - #2030

Adds several connection-recovery improvements aimed at the class of failures
where publishing is broken even though the peer connection still reports
connected:

- Act on local `ConnectionQuality.Lost`: when the server reports it isn't
  receiving our media for a sustained period while connected and publishing,
  force a full reconnect.
- Verify the ICE restart actually landed during a resume (wait for
  `restartingIce` to clear via a matching-offerId answer) instead of only
  waiting for `connected`, and escalate a rejected publisher answer during a
  resume to a full reconnect.
- Recreate the peer connection (via escalation) when an ICE restart is needed
  but there is no remote description to restart on, rather than stalling on
  `renegotiate`.
- Add outbound-RTP liveness to `verifyTransport()` (bytesSent must advance with
  active senders) and bound how long a transport may stay CONNECTING.
- Preserve a full-reconnect request that arrives mid-resume so a successful
  resume no longer clears it.
- On a detected connection state mismatch, attempt a full reconnect (keeping the
  room alive) instead of tearing the session down.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Reverts the resumeConnection change that blocked the resume until the
publisher's ICE restart offer was answered (`restartingIce` cleared). When only
the signal blips but the media path is fine, the server may never answer the
resume's ICE-restart offer, so gating on it hangs the resume and it never emits
`resumed` (regressed the signalDisconnectDuringResume e2e test).

A stale-but-connected publisher is instead caught at runtime by the local
`ConnectionQuality.Lost` handler and the outbound-RTP liveness check in
`verifyTransport()`, without breaking resume semantics.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

The bytesSent-advancing heuristic false-positives on legitimate custom tracks
that don't emit media continuously (static screen share, on-demand canvas,
silent/push-to-talk audio), triggering unnecessary reconnects. Remove it and
revert verifyTransport to a synchronous check.

The "stop treating an indefinitely-connecting transport as healthy" bound is
kept — it's about connection state, not media, so it doesn't share the
false-positive concern. Detection of a genuinely broken publish path is left to
the server-driven local ConnectionQuality.Lost handling.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

…nsition

verifyTransport() owned transportConnectingSince but leaked it on several exit
paths (no pcManager, ws closed, the stuck verdict) and across
cleanupPeerConnections(), so a timestamp captured before a failure survived the
teardown/rebuild. Since Room pauses the reconcile during Resuming/Restarting and
resumes it only after recovery, the first post-recovery tick that saw CONNECTING
measured against the ancient timestamp and instantly reported the transport as
stuck, causing a spurious extra reconnect.

Record the entry time in the pcManager state-change handler (which only fires on
real transitions, overwriting on each entry into CONNECTING) and make
verifyTransport() a pure read that fails open when no timestamp is recorded. Also
clear it in cleanupPeerConnections() for the paths where onStateChange is
detached before teardown.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

scheduleLostQualityReconnect's countdown was only cancelled by a non-LOST
quality update or close(), not when a reconnect starts. A countdown armed from a
previous session's LOST verdict could fire shortly after a fast reconnect
completed and force another full reconnect, before the server had evaluated the
new session.

Clear it at the start of attemptReconnect so the countdown always reflects the
current session. attemptReconnect (rather than cleanupPeerConnections) is the
single entry point that also covers the resume path, which keeps its peer
connections.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

…onnect

attemptReconnect only preserved a full-reconnect request that arrived during a
resume. When the attempt itself was a full reconnect, the success path
unconditionally cleared fullReconnectOnNext, discarding a request (e.g. a server
RECONNECT leave) that arrived while restartConnection() was running — its
zero-delay reconnect was a no-op under the attemptingReconnect guard and then
wiped by clearPendingReconnect().

Consume the flag at the start of the attempt (read into a local, reset to false)
so any true value seen afterwards is unambiguously a new request, handled by the
existing finally dispatch for both paths. The catch still escalates a failed full
reconnect back to a full reconnect.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>